Gopher Proxy
gopherpedia.com:70 gopherpedia.com:70/0//MQTT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
======================================================================
= MQTT =
======================================================================
Introduction
======================================================================
MQTT is a lightweight, publish-subscribe, machine-to-machine network
protocol for message queueing/message queuing services. It is designed
for connections with remote locations that have devices with resource
constraints or limited network bandwidth, such as in the Internet of
things (IoT). It must run over a transport protocol that provides
ordered, lossless, bi-directional connections--typically, TCP/IP. It
is an open OASIS standard and an ISO recommendation (ISO/IEC 20922).
History
======================================================================
Andy Stanford-Clark (IBM) and [https://cirrus-link.com/ Arlen Nipper]
(then working for Arcom Control Systems) authored the first version of
the protocol in 1999. It was used to monitor oil pipelines within the
SCADA industrial control system. The goal was to have a protocol that
is bandwidth-efficient, lightweight and uses little battery power,
because the devices were connected via satellite link, which was
extremely expensive at that time.
Historically, the "MQ" in "MQTT" came from the IBM MQ (then
"MQSeries") product line, where it stands for "Message Queue".
However, the protocol provides publish-and-subscribe messaging (no
queues, in spite of the name). In the specification opened by IBM, as
version 3.1, the protocol was referred to as "MQ Telemetry Transport".
Subsequent versions released by OASIS strictly refer to the protocol
as just "MQTT", although the technical committee itself is named
"OASIS Message Queuing Telemetry Transport Technical Committee". Since
2013, "MQTT" does not stand for anything.
In 2013, IBM submitted MQTT v3.1 to the OASIS specification body with
a charter that ensured only minor changes to the specification could
be accepted. After taking over maintenance of the standard from IBM,
OASIS released version 3.1.1 on October 29, 2014. A more substantial
upgrade to MQTT version 5, adding several new features, was released
on March 7, 2019.
Derived specifications
========================
MQTT-SN (MQTT for Sensor Networks) is a variation of the main protocol
aimed at battery-powered embedded devices on non-TCP/IP networks. Any
network that provides for bidirectional transport may be used (such as
UDP and serial links), though Zigbee is the original design target.
Communication within a MQTT-SN network as well as to the outside MQTT
network is coordinated by a "MQTT-SN Gateway".
Overview
======================================================================
The MQTT protocol defines two types of network entities: a message
broker and a number of clients. An MQTT broker is a server that
receives messages from publishing clients and then routes the messages
to the appropriate destination clients. An MQTT client is any device
(from a microcontroller up to a full-fledged server) that runs an MQTT
library and connects to an MQTT broker over a network.
Information is organized in a hierarchy of topics. When a publisher
has a new item of data to distribute, it sends a control message with
the data to the connected broker. The broker then distributes the
information to any clients that have subscribed to that topic. The
publisher does not need to have any data on the number or locations of
subscribers; and subscribers, in turn, do not have to be configured
with any data about the publishers.
If a broker receives a message on a topic for which there are no
current subscribers, the broker discards the message unless the
publisher of the message designated the message as a retained message.
A retained message is a normal MQTT message with the retained flag set
to true. The broker stores the last retained message and the
corresponding quality of service (QoS) for the selected topic. Each
client that subscribes to a topic pattern that matches the topic of
the retained message receives the retained message immediately after
they subscribe. The broker stores only one retained message per topic.
This allows new subscribers to a topic to receive the most current
value rather than waiting for the next update from a publisher.
When a publishing client first connects to the broker, it can set up a
default message to be sent to subscribers if the broker detects that
the publishing client has unexpectedly disconnected from the broker.
Clients only interact with a broker, but a system may contain several
broker servers that exchange data based on their current subscribers'
topics.
A minimal MQTT control message can be as little as two bytes of data.
A control message can carry nearly 256 megabytes of data if needed.
There are 14 defined message types used to connect and disconnect a
client from a broker, to publish data, to acknowledge receipt of data,
and to supervise the connection between client and server.
MQTT relies on the TCP protocol for data transmission. A variant,
MQTT-SN, is used over other transports such as UDP or Bluetooth.
MQTT sends connection credentials in plain text format and does not
include any measures for security or authentication. This can be
provided by using TLS to encrypt and protect the transferred
information against interception, modification or forgery.
The default unencrypted MQTT port is 1883. The encrypted port is 8883.
MQTT broker
======================================================================
The MQTT broker is a piece of software running on a computer (running
on-premises or in the cloud), and could be self-built or hosted by a
third party. It is available in both open source and proprietary
implementations.
The broker acts as a post office. MQTT clients do not use a direct
connection address of the intended recipient, but use the subject line
called "Topic". Anyone who subscribes receives a copy of all messages
for that topic. Multiple clients can subscribe to a topic from a
single broker (one to many capability), and a single client can
register subscriptions to topics with multiple brokers (many to one).
Each client can both produce and receive data by both publishing and
subscribing, i.e. the devices can publish sensor data and still be
able to receive the configuration information or control commands
(MQTT is a bi-directional communication protocol). This helps in both
sharing data, managing and controlling devices. A client cannot
broadcast the same data to a range of topics, and must publish
multiple messages to the broker, each with a single topic given.
With the MQTT broker architecture, the client devices and server
application become decoupled. In this way, the clients are kept
unaware of each other's information. MQTT, if configured to, can use
TLS encryption with certificate, username and password protected
connections. Optionally, the connection may require certification, in
the form of a certificate file that a client provides and must match
with the server's copy.
In case of failure, the broker software and clients can automatically
hand over to a redundant/automatic backup broker. Backup brokers can
also be set up to share the load of clients across multiple servers on
site, in the cloud, or a combination of these.
The broker can support both standard MQTT and MQTT for compliant
specifications such as Sparkplug. This can be done with the same
server, at the same time and with the same levels of security.
The broker keeps track of all the session's information as the device
goes on and off, in a function called "persistent sessions". In this
state, a broker will store both connection info for each client,
topics each client has subscribed to, and any messages for a topic
with a QoS of 1 or 2.
The main advantages of an MQTT broker are:
# Elimination of vulnerable and insecure client connections (when
appropriately configured).
# Ability to easily scale from a single device to thousands.
# Management and tracking of client connection states, including
security credentials and certificates (when appropriately configured).
# Reduction of strain on cellular or satellite networks without
compromising security (when appropriately configured).
Connect
=========
Waits for a connection to be established with the server and creates a
link between the nodes.
Disconnect
============
Waits for the MQTT client to finish any work it must do, and for the
TCP/IP session to disconnect.
Publish
=========
Returns immediately to the application thread after passing the
request to the MQTT client.
Version 5.0
======================================================================
In 2019, OASIS released the official MQTT 5.0 standard. Version 5.0
includes the following major new features:
* Reason codes: Acknowledgements now support return codes, which
provide a reason for a failure.
* Shared subscriptions: Allow the load to be balanced across clients,
thus reducing the risk of load problems.
* Message expiry: Messages can include an expiry date and are deleted
if they are not delivered within this time period.
* Topic alias: The name of a topic can be replaced with a single
number.
Quality of service
======================================================================
Each connection to the broker can specify a QoS measure. These are
classified in increasing order of overhead:
* At most once - the message is sent only once and the client and
broker take no additional steps to acknowledge delivery (fire and
forget).
* At least once - the message is re-tried by the sender multiple times
until acknowledgement is received (acknowledged delivery).
* Exactly once - the sender and receiver engage in a two-level
handshake to ensure only one copy of the message is received (assured
delivery).
This field does not affect handling of the underlying TCP data
transmissions; it is only used between MQTT senders and receivers.
Security
======================================================================
MQTT protocol version 3.1.1 requires the server (broker) to use a
timeout that is one-and-a-half times the keepalive value specified by
the client. This (and similar keepalive functionalities in other
protocols such as HTTP) enables a slow DoS attack published in 2020
called SlowITe, in which the attacker tries to open and maintain as
many connections as possible, depriving legitimate users of their
connections. New variations of the attack and new detection/mitigation
methods are topics of current research.
Clustering
======================================================================
MQTT clustering is a technique employed to ensure high availability,
fault tolerance, and scalability in MQTT deployments. As an efficient
and lightweight messaging protocol, MQTT clustering allows for the
creation of a resilient network of interconnected broker nodes,
ensuring continuous and reliable message delivery even in the face of
hardware failures or network disruptions.
Message ordering
==================
MQTT does not guarantee that messages published by independent clients
arrive at subscribers in the order they were generated. The OASIS MQTT
specification provides ordering guarantees only within a single client
session on a single topic; events originating from separate clients or
generated across independent connections may be delivered out of
sequence.
This limitation is particularly consequential in IoT deployments that
use MQTT lifecycle events (connect and disconnect notifications) to
track device connectivity state. Major broker implementations
acknowledge this directly: Amazon Web Services states in its AWS IoT
Core developer documentation that "lifecycle messages might be sent
out of order" and that subscribers "might receive duplicate messages".
Similarly, HiveMQ's engineering documentation notes that "strict
ordering across publishing clients requires additional strategies such
as dedicated routing and sequence numbers."
The practical consequence is that a disconnect notification generated
before a reconnect notification may arrive at the subscribing
application after it, causing monitoring systems that apply a
last-write-wins policy to record a device as offline when it has
already reconnected. This is a known failure mode in event-driven
architectures and was characterised in the distributed systems
literature as an inherent property of asynchronous message passing by
Leslie Lamport in 1978. Independent benchmarks have documented the
operational cost of event ordering inversions in production IoT
deployments.
Commonly applied mitigations include debounce windows (delaying action
on disconnect events for a fixed interval to allow late-arriving
messages to be processed), polling or re-query patterns, and
application-layer sequence numbering. Each mitigation imposes
trade-offs: debounce windows introduce detection latency for genuine
disconnect events and may suppress legitimate notifications; polling
adds network overhead and is unsuitable for passive sensors.
See also
======================================================================
*Comparison of MQTT implementations
*Advanced Message Queuing Protocol (AMQP)
*Streaming Text Oriented Messaging Protocol (STOMP)
*Constrained Application Protocol (CoAP)
*Apache ActiveMQ
*Solace PubSub+
*RabbitMQ
License
=========
All content on Gopherpedia comes from Wikipedia, and is licensed under CC-BY-SA
License URL: http://creativecommons.org/licenses/by-sa/3.0/
Original Article: http://en.wikipedia.org/wiki/MQTT
.
you're on gopherpedia.com^70/0//MQTT
back link is gopherpedia.com:70/1/